Computer operating systems such as DOS and OS/2, and more particularly the mechanisms for creating, storing, and retrieving data files and directories associated with the operating systems, are generally well known. Mature and powerful file storage systems have evolved which allow the application programmer to focus on the functionality of the application program, leaving to the operating system the tasks of creating files and directories, allocating disk space (whether local storage or remote file server storage), and file retrieval schemes largely to the operating system. Indeed, many sophisticated application programs, tools, and the like simply implement a function call (or a "request") to the operating system which is transparent to the user, whereupon the operating system implements the tasks of file creation, storage, retrieval, and the like.
For example, in response to a function call from an application, an operating system may retrieve data (whether text, graphics, video, or the like) from memory and create a file for that data, storing the data at a specific location within the data storage unit (e.g., hard drive, file server). In addition, the operating system typically stores along with the file a set of information known as standard attributes. Common standard attribute sets for a data file often include attributes such as the file name, the date and time of most recent access to the file as well as the date and time of the last revision, security (which identifies those users authorized to access the file), and the like. As application and other programs have become more complex, the operating system is required to track information or attributes relating to a file in addition to the standard attributes. Thus, the need for managing such extended attributes for files, directories, and the like has arisen. Although it is theoretically possible to simply expand the list of standard attributes to include these extended attributes, many extended attributes are unique to a very narrow application program and, hence, to expand the list of standard attributes to include all extended attributes from all applications would unnecessarily increase the size and complexity of standard attribute sets.
Storage of files and their associated standard attributes is generally managed by operating systems in a linked manner. i.e., as though both the file and standard attribute set were a single entity, even though they may be stored at different locations in storage. For a more comprehensive discussion of file storage, see Feigenbaum, et al., U.S. Pat. No. 5,367,671 issued Nov. 22, 1994, Baird, et al., U.S. Pat. No. 5,218,696 issued Jun. 8, 1993, and Johnson, et al., U.S. Pat. No. 5,113,519 issued May 12, 1992, the entire disclosures of which are hereby incorporated herein by this reference.
One advantage associated with extended attributes surrounds the fact that, in many instances, an extended attribute is treated by the data storage and retrieval system as being different from a file. In particular, a file is typically assigned a file name, whereupon the file name is typically cataloged in a directory along with other information relating to the file, for example indicia of the storage location of the standard attributes associated with the file, the storage location of any extended attributes which may be associated with the file, and the storage location of the actual data within the file (or at least the location in storage of the first data cluster for the file, which first data cluster directs the operating system to subsequent data clusters within which the data pertaining to the file are stored).
An extended attribute, on the other hand, typically does not require a separate entry in a directory, but rather may simply be logically linked to the file name, for example through a logical link created by the application or operating system which governs the creation of the extended attribute. In one sense, an extended attribute is simply a shorthand way of associating additional information with the file in a convenient and efficient manner. This shortcut approach is attractive to application developers since it conserves processing time, disk space, and the like.
The application programmer is thus afforded a great deal of flexibility in designing and implementing extended attributes associated with a file. Indeed, it is this flexibility, in concert with the application's specific extended attribute scheme created in the context of a particular application or operating system, which contributes to the non-interchangeability of extended attributes across operating systems or among different (distinguishable) applications.
Two principle schemes have evolved in the prior art for managing extended attributes. In the first scheme, the operating system creates a standard file which includes the data associated with the file as well as the standard attributes for that file. The operating system further creates a second file within which the extended attribute information is stored. The relationship and, hence, the logical link, between a standard file and the extended attribute file is maintained by the application. However, when the file is subsequently accessed by a different application, tool, or the like, the "link" between the standard file and the extended attribute file is lost, such that the extended attribute information is typically irretrievable by an application other than that which created the original file and its extended attribute file.
In the second scheme, the extended attributes are appended to the standard file, for example at the beginning of the file or at the end of the file, whereby the application which created the extended attributes "remembers" which storage sectors embody the information pertaining to the data file and its standard attributes, and which sectors of storage are reserved for the extended attribute information. Again, when the file is subsequently retrieved by a different application, only the file information and standard attributes are typically accessible.
Feigenbaum, et al. discloses a methodology for allocating and conjointly managing access to storage for a file and its associated extended attributes. In particular, a single directory listing is made for the file which includes the file name, indicia of the file's location in storage, and indicia of the location in storage of an extended attribute associated with the file.
The Feigenbaum, et al. scheme permits additional extended attributes to be created for the same base file, whereupon an additional notation is made as to the location in storage of the subsequent extended attributes. Thus, when the application which created the file and extended attributes subsequently retrieves that file, all extended attributes associated with that file which were created by the same application may also be accessed, if desired. However, if additional extended attributes are created for an existing file through an application other than the application which created the original main file and/or the original extended attributes, the subsequent application is incapable of accessing the original extended attributes created by the first application.
A system and method for managing extended attributes which are created and accessed by different or distinguishable operating systems, applications, and the like, is needed which overcomes the shortcomings of the prior art. In particular, a system is needed which includes an architecture for extended attributes for providing improved file system management, maintenance, and control by creating and storing a database inside the extended attribute structures.